10.3 resolved issues
This section lists significant issues that have been addressed in IEE 10.3.2.
AMI Billing Export (ABE)
2759060: (SR#: 01133286) During a volume test, the SAP Billing Export task raised the following error when processing the ABE export files: Unexpected System Exception: #XmlException - Root element is missing. received - contact Application manager.
Resolution: This was because ABE copied the tmp file to a new XML export file, and the XML file was picked up before this process completed. The ABE logic has been enhanced. It now renames the tmp file to XML instead of creating a new file, no longer picks up the file if it is empty, and ensures it never creates empty files.
2769063: (SR#: 01137947) IEE 10.3 ABE queue did not show the details for ID Resolution and Invalid Request Item exceptions.
Resolution: The existing logic for Meter ID to eliminate display formula channels in ABE dashboard did not suffice all the scenarios. It addresses formula channels but there are other entries where Meter ID can be null, for example, Resolution and Invalid Request Item exception categories. The logic to exclude formula channels has been changed by adding a where clause on the formula key rather than Meter ID because this will effectively isolate only formula channels leaving other entities intact.
2773982: (SR#: 01138270) When an ABE request placed across a meter swap in the summary section count shows as 1, but in the "Detail" section shows as 2, the rows appeared due to 2 meters.
Resolution: The summary count displayed only errors not warnings, but the detail count displays both warnings and errors. The logic has been changed in "HVBE_MON__ENTITYLIST_GET" procedure to consider the exception category (if provided) along with the entity key. In meter swap scenarios, if the exception category has both old and new meters then it will pick only the new meter. And modified the "HVBE_MON_SUMMARYDATACUR_GET" procedure to display both warnings as well as errors.
2806761: (SR#: 01152203) Service Point ID, Endpoint ID, Multiplier, and UDA values were not displaying on ABE.
Resolution: There was an issue while joining Flat Config Physical and Flat Config Attribute tables with HVBE Entity table. While joining these tables, we were not considering the entity type of the HVBE Entity table. The join condition based on the entity type has been corrected.
2810808: (SR#: NA) Demand Response API was not working properly because we were not handling stale meter use cases.
Resolution: The logic in the ABE code that decides which readings to pick for export was not exactly following the complex requirements. Changed the logic as part of the resolution, so that the stale meter reads are handled properly and is in-line with the other reads.
2880372: (SR#: 01182533) For some MRO requests from SAP for a specific month, it was observed that IEE returned a read with for the month prior or the month after.
Resolution: This issue occurred when ABE processes more than one request simultaneously for the same meter and the same channel, but with different dates. When selecting the read, ABE did not consider the date in the individual request and returned the same read selected for the first request. This issue does not occur when the requests are received and processed separately. The ABE process has been corrected. In this scenario, ABE now selects the correct read for each request. The fix is in IEE core (ABE). No change in ISAIM.
2896180: (SR#: 01190890) Historical meters not displaying in ABE after upgrading to version 10.3.
Resolution: In meter swap scenario, if old and new meters were coming as part of the same ABE requests, then we were displaying only new meters. We reverted the changes to before Bug 2773982: (SR#: 01138270) When an ABE request placed across a meter swap in the summary section count shows as 1, but in the "Detail" section shows as 2, the rows appeared due to 2 meters. fix and are displaying both old and new meters even if they are of the same ABE request.
3082097: (SR#: 01293772) ABE was failing to export the closest to SRD MAX KW when there were two KW reads with the same value in the KW search window.
Resolution: The code that selects the peak reading (when there are more than one KW reading matching the various conditions), was selecting the biggest one. But when there were two peak readings with the same value, it would not pick the one that was closest to the selected consumption one. To fix this, additional checks were added, so in this rare situation it will pick the one closest to the consumption reading.
3212868: (SR#: 01359956) When looking for the register reads in the expanded register search window, IEE can only select +1 Day Register Read but failed to select -1 day read even if it was available.
Resolution: Changed the BDCalc code, so for this special PEAK case, it will look for closest to billstopdate KWh reading in the whole search window, after billstop. And in cases when there are 2 readings equally spaced from billstop (left and right) - it will select the left one.
AMI Data Export (ADE)
2739958: (SR#: 01106339) When trying to export the daily readings, the export times were running long causing a manual workaround.
Resolution: The root cause for this issue was that when fetching configurations in ADE, even though ADE passes in effective dates, we were seeing calls to the Meter_get or other entity procedures from BOT to EOT. This can only be turned off when the setting Build Object Graph equals false. To resolve this issue, we built a new Configuration Result Set object using collection from meter fetch, and then use this new object in an existing ADE method like Get Cc Collections For Entity Type. The performance is much faster as effective dates are considered in entity_get procs like Meter_get with the above-mentioned changes.
2744748: (SR#: 01124269) ADE Exports was failing to complete and was consuming all the system memory, which eventually caused the server to crash.
Resolution: When the ADE code was traversing through the critical changes based on the dates on the node-link and correlating with the dates defined in the ADE request. During the processing of this, it was sorting the entity IDs based on the time. This sorting was not properly implemented and so it caused this issue. The ADE code that is traversing critical change has been changed so that it sorts based on Start and End Date.
2783148: (SR#: 01142973) AMI Data Export (ADE) was not working with non-electric UOMs for export.
Resolution: The root cause of this issue was that the Unit Category for KGAL and GAL was “undefined” in the Unit Category Unit table. There was a total of 161 units in the Unit Category Unit table that have Unit Category undefined”. So, during ADE export, for Unit Scaling, the last unit was being fetched from those 161 units, which had a scaling factor 1 but different UOM Class than KGAL (KGAL UOM class is water). Due to this mismatch in UOM Class and Unit class, it was not able to find any UOM for conversion (returning null). This is the reason conversion was not happening in water reads. To resolve this issue, the mapping has been corrected to work for non-electric UOMs for ADE export.
2800400: (SR#: 01138189) AMI Data Export (ADE) export was failing with an error.
Resolution: Error occurring while logging, the system checked the event to log. In some cases, if there were no events, the logging framework tried to initialize the log object as a part of recursive code. The system threw an object reference error since there were no events available to initialize. This issue was addressed by adding a null check. When there are no events, the system will check for null, and will initialize the log object with default events.
3038357: (SR#: 01265222) When there was a single configuration with a SPC that was not aligned with SPC, the export task never completed and consumed all the available memory on the app server.
Resolution: To resolve this issue, the code has been corrected.
3048470: (SR#: 01271314) Object reference error was observed during ADE export.
Resolution: When no readings were available for a service point channel in the given date range, the Export functionality was broken by throwing a null reference error in AddConfigurationEntities. The required null check in AddConfigurationEntities function was added to continue the ADE export.
3168817: (SR#: 01343668) When there were account versions and service point channel versions that were not aligned, and if we sent service point channel collection 1st, critical change finder went into an infinite loop.
Resolution: Based on the entity we were considering only that particular collection, in case of service point entity export, we were not considering other entities like account to find critical change. The gap in the critical change finder was removed in the "ServicePointChannel_To_IntervalChannel" nodelink. This is now working as expected.
AMI Readings Import (ARI)
3042952: (SR#: 01268068) The VE service needed to be restarted every time a new work bin was added after the VE service was running, otherwise it would not pick up clean readings from the newly added work bin.
Resolution: The work bin list is now updated when VE runner starts for the current day during the data collection window (DCW).
3129171: (SR#: 01313937) VE task runner process cannot access the files.
Resolution: CRITICAL ERROR message: The process cannot access the file because it is being used by another process and workbin files fail but have no logs associated with the file. There is no mechanism to troubleshoot these failures to detect the issues causing the Fail state. Added retry logic to load the work file to memory 3 times with incremental delay.
Billing
3252197: (SR#: NA) Customer reported issues with the user interface when removing meters, as it generated errors for certain configurations.
Resolution: To resolve this issue, the AllowPartialHistory bool variable for the LinkedMeters object was configured to ignore warnings and proceed to save the configurations.
Configuration
2841152: (SR#: 01162626) Service point was getting updated with incorrect address without even accessing the address section of the UI.
Resolution: When the Country Code is not mentioned in the payload, by default "United States" was being updated in the current code and so this issue is resulting. We have removed the default country code from the code when the country code is null or empty in the sample XML file.
2912110: (SR#: 01196520) Configuration maintenance screen was taking too long to load.
Resolution: While fetching the node links related to service point, nodelink_get was taking time due to high number of reads. Added index which reduced the number of reads and increased the performance.
2937322: (SR#: 01207568) On the Configuration Maintenance (Advanced) screen, displaying an existing channel set or adding a new channel set gave the following error message: Object Reference Not Set to an Instance of the Object on Existing or Adding a New Set.
Resolution: The Configuration Maintenance (Advanced) screen has been corrected.
3006419: (SR#: 01217959) The customer was not able to view the map in CSR.
Resolution: Coordinates passed as arguments for Google Maps API were wrong. The code was corrected, and the arguments have been passed to Google Maps API.
3110925: (SR# NA) SQL Server could not exclude multiple service points from a dynamic group.
Resolution: For the multiple service point selection in Group Maintenance, we use the pipeline operator, but in the code pipeline operator is not replaced with a comma operator, which is causing this issue. The logic has been changed; when including/excluding multiple service points, we use with pipeline operator and internally replace the pipeline operator with a comma in the code and use with In or Not Operator.
Database
2803209: (SR#: 01150996) Indexes and other schema object definitions were not correct after running an upgrade.
Resolution: Some of the indexes were added only through upgrade scripts, they were not reflecting as part of table definition scripts causing a difference in newly built schema and upgraded schema.
2818170: (SR#: 01152983) After running the Verify DB script to confirm the database upgrade was successful, the script identified discrepancies between actual schema and upgraded schema.
Resolution: Created upgrade and manual scripts to fix the discrepancies observed during upgrade.
2860995: (SR#: 01172053) Duplicate reading statuses were in the Reading Status table.
Resolution: This is affecting the upgrade module only. From 10. x onwards we are using 64-bit status instead of 32-bit, to support this functionality we are utilizing the column StatusExt1. Prior to 10.x this column was null. When the user loads the file in 10.x it was searching for the combination of Status and StatusExt1, if StatusExt1 is null then it inserts one more record for the same status with StatusExt1 as zero(0x0000000000000000000000000000000000000000000000000000000000000000). Hence it created duplicate status in the ReadingReadingStatus table. To resolve this issue, we upgraded the script to update StatusExt1 to"0x0000000000000000000000000000000000000000000000000000000000000000" for non-duplicate Status's, and we ran a manual script (Remove_Duplicate_Status_RRS) to fix the duplicated status.
Device Comm
3194712: (SR#: 01356351) DeviceCommLog deadlocked on contingency read request messages.
Resolution: Suggested index (IX_DCL_DEVICECOMMLOGKEY) will help reduce the number of rows scanned and locked during a query. This means fewer resources are locked for shorter periods of time, which can lower the chances of a deadlock. Also ensured that the database engine accesses rows are in a consistent order. This reduces the likelihood of circular wait conditions, which are a common cause of deadlocks.
Device Events
2864512: (SR#: 01175745) For remote disconnect/reconnect request from SAP, ISAIM returned an exception.
Resolution: This issue occurs when SAP clock is a few seconds ahead of IEE clock. The AMI disconnect/reconnect is created as future dated task, and the Correlation ID is not saved. Even when the disconnect/reconnect is successful, ISAIM cannot find the task using Correlation ID and logs an error. The AMI disconnect/reconnect has been corrected. Added a time buffer, so when SAP clock is a few seconds out of sync, the disconnect/reconnect is not created as a future dated task. When the disconnect/reconnect request is future dated, the Correlation ID is saved as task parameter, so ISAIM can return the correct result. The fix is in IEE core (DeviceComm). No change in ISAIM.
3235787: (SR#: 01373403) 'RUN' button was not available for Device Event report.
Resolution: When the desktop Scale Factor is set to 125%, it is causing scaling issues due to DPI. The IgnoreClientDesktopScaleFactor is now set to 1 so that it ignores the remote machine scale factor when local machine is rendering the remote desktop services.
Estimation
2806852: (SR#: 01152436) During daily monitoring of the production in the IEE system, records were being left in the Estimation to-do table after the finalization window closed.
Resolution: The Estimation Service is running slower than usual on Production. There were over 14,000 records in the estimation to-do table after the finalization window closed. Logged the following error message: 2022-11-12 04:41:05,164 1000 ERROR [30] Itron.EE.Service.Common.Estimation.BulkScalingOperationWorker:0 ExecuteWorkItemString[] {Unexpected Exception: Object reference not set to an instance of anobject. - EstimationWorker ThreadPoolCallback blew out due to this exception.,Object reference not set to an instance of an object.} System.NullReferenceException: Object reference not set to an instance of an object. atItron.EE.Business.Validation.VE.Extended.ExtendedScalingProcessor.LoadRegisterChannels(ExtendedScalingResultresult) atItron.EE.Business.Validation.VE.Extended.ExtendedScalingProcessor.Scale(ExtendedScalingRequestCollectionrequests, ExtendedSaveParameters saveParameters) atItron.EE.Service.Common.Estimation.BulkScalingOperationWorker.DoEstimates() atItron.EE.Service.Common.Estimation.EstimationWorker.ThreadPoolCallback().
There is slowness observed in SUE functionality in 10.x. The reason for this is that in 9.0, when using SUE, we used to bulk fetch SPCs and readings before passing along Estimation To Do entry to the Business layer. Now in 10. X with TOU scaling, we no longer bulk fetch SPCs and send every request to the business layer. If the request has no register reads for bulk scaling, we are sending every request to the business layer for processing. We have added back earlier code to bulk fetch SPCs and store them in the dictionary. For regular scaling, we used the previous optimization which checks if the link register channel exists, and it has at least one read. For TOU scaling it can happen without a linked register channel or link register read because TOU scaling uses a TOU set not a meter read set. In this case, pass the request along to the business layer even if they don't exist if we have found the SPC interval channel.
Event Import
3211894: (SR#: 01358510) The Enhanced Event Import task runners were corrupting the error data on BadMapping and BadDevices.
Resolution: The enhanced Event Import task processor is corrupting the <EventID> data message payload when the data is processed to the *\error folder for BadMapping and BadDevices. The case of event ID in the error file is changing the ID to an uppercase ID, which is causing the confusion while analyzing the error. This issue was fixed by removing the case change event ID function wrongly coded earlier.
Export
3103519: (SR#: 01278467) IEE Events / Alarms were not being exported.
Resolution: The issue is coming when event data value length is greater than 500, because in the database table event data value column length have 500. The code logic when event data value is greater than 500, then truncate the value till 500.
Extract, transform, and load (ETL)
2889729: (SR#: 01187120) Flat Configuration Physical (FCP) update task from the task scheduler was consistently throwing an error.
Resolution: This issue was caused by introducing an optional parameter. To resolve this issue, the optional parameter has been removed.
Import Data Manager (IDM)
2863080: (SR#: 01175192) Performance issues with banked data processing.
Resolution: As part of the resolution, we have reverted the change done to fix the unit test case which was causing the performance issue. Bank data resubmission and Import Data Manager-related functionalities are to be tested.
Meter Data Management (MDM)
3052001: (SR#: 01272399) Configuration Export task with the Request Type "Group" and "Since Last Export" boxes checked errored out with every run.
Resolution: After processing the first chunk of the configuration export, we closed the XML writer and stream resulting in an object reference error and only exporting the first chunk of the configuration export. As part of the resolution for this bug, we are closing the XML writer after processing the final chunk of the configuration export.
3054465: (SR#: 01260866) Configuration Export was not operating correctly when the meter's initial version is associated to one program and other version is associated with different program, and then this new version is associated to a Service point.
Resolution: When there are multiple meter versions IEE tries to find the version on the meter version change date but before that the meter was not associated with any Service point, so, it returned null and threw an exception when it tried to fetch the channel details for that version. The code has been changed to add the null check if there is no meter version found.
3132601: (SR#: 01311045) In Program Configuration Manager, filters were not working properly for meter/service point programs.
Resolution: The root cause of this issue was when selecting channel count with channel type (for example, Interval or Register), it was not filtering the program as per selection criteria. The code has been changed so that when selecting the channel count and channel type it works exactly as per the selection criteria.
Platform
2735880: (SR#: 01122248) IEE threw a duplicate Read Status Code External System Type Mappings error when trying to add/remove an external read status.
Resolution: A code-fix was done to restrict duplicate priority code mappings only and not all the code mappings.
2781695: (SR#: 01141066) When fetching the audit log by action type it fetched all AuditLogDetail rows with action type and did not filter by date range in the UI causing the UI to freeze.
Resolution: AuditLogDetail fetch has no date range because the table does not contain any date columns. The resolution is provided by first fetching the AuditLogEntry subset for the date range in the UI, then using that subset to fetch AuditLogDetail. This allows AuditLogDetail fetch to only fetch records for the date range in the UI. Then trim down the first fetch AuditLogEntry subset for only records that are returned from AuditLogDetail fetch.
2799860: (SR#: 01148914) IEE: ReadingPurgeByPartition procedure was not loading all eligible SPCNodeIDs in the main template table to purge.
Resolution: The missing empty status update in ReadingPeriodWithStatusID table was due to some of the SPCNodeIDs not being captured in the main t_Purge_Reading_all table because it's targeted to capture of one day at a time, and not considering the records in the ReadingGroupSPC table with the purge date falling between the StartTime and Endtime. Having the filter condition 'v_interimpurgedate between g.StartTime and g.EndTime' while populalting t_purge_reading_all will resolve this issue, but it will pull the same row in multiple iteration (2 times), which will increase the data volume in t_purge_reading_all table and try to process the same record for multiple times resulting in an impact to the performance. Identified the list of SPCNodeIDs that are missing the empty status update in the ReadingPeriodWithStatusID table for the purge period at the end of the main Loop. Applied the update, split and merge on ReadingPeriodWithStatusID table for those SPCNodeIDs alone, and deleted the records from ReadingCreationEditLog and ReadingEditLog tables for the purge period.
2832662: (SR#: 01161201) Customer was getting an unhandled exception when querying in the IEE Audit screen.
Resolution: While fetching UDA nodes, we are not fetching the result set to allow link between nodes. This was causing exceptions in the Audit log screen because sometimes certain UDAs must fetch linked entities to find IDs. We have provided the resolution to assign a new result set to the collector returned from FetchCollectionFromNodeKeys. This creates a link between nodes. Like Interval Channel to Meter link.
2817664: (SR#: 01152996) The following intermittent error was observed with Reading Purge by Partition: Unexpected System Exception:#[20001] ORA-20001: Original Error Message -8103: ORA-08103: object no longer exists.
Resolution: This error occurred very rare when tables are being dropped/truncated while a SQL statement for those tables is still in execution, or in the case of an index, it might be caused by an index rebuild i.e., when the object has been deleted by another session since the operation began. The Reading Purge by Partition has been corrected to handle this exception.
2865119: (SR#: 01175841) Reading Purge by Partitions TimeToRun was taking too long to process.
Resolution: The code was changed to consider only the SPCNodeIDs as part of the Working Chunk than all on each iteration.
2881039: (SR#: 01182117) Log information was not writing to task, so customer was not able to investigate the issues on task level.
Resolution: We have reverted the Bug #2026428 changes to avoid unhandled error.
2890119: (SR#: 01181610) When fetching AuditLogEntry using a specific entity, the system was still pre-fetching AuditLogEntry.
Resolution: We removed the code to pre-fetch AuditLogEntry because it was making the performance worse when querying years of audit logs.
2986650: (SR#: 01233016) While executing purge module, customer was getting ORA-00060: deadlock detected while waiting for resource Error Stack Trace.
Resolution: The selection criteria for delete T$_workReadingChunkis different than the selection criteria for inserting into T$_workReadingChunk. Since there was no uniqueness for the columns it was using for the selection criteria for delete. Included rows order column to delete statement to prevent deleting rows that belong to another task.
2986657: (SR#: 01233056) While executing Reading Purge by Partition, a unique constraint error occurred on ReadingPeriodWithStatusID and ended the execution prematurely, leaving unpurged data in the database.
Resolution: The SPCNodeID in Message Log table code has been enhanced to include exception handling logic to avoid premature execution.
3038348: (SR#: 01265204) When requesting audit information for a service point, the Audit Log user interface was not responding.
Resolution: This was because multiple entity IDs were changed in the same transaction. The Audit Log user interface was enhanced to support showing multiple entity IDs that were changed in the same transaction. On the "Records for object in time period" table, they will be displayed separated by a comma, in the same order as they are listed as separate rows on the "Audit Log Entry Details" table at the bottom.
Purge
3050186: (SR# 1270710) Reading Purge By partition was taking a long time to execute and was not able to purge the partition, which is read only.
Resolution: The logic has been changed. If partition is read only then mark partition as Read-Write before purge. Continue to purge if non-partition table data is eligible for purge until Command time out "OR" purge gets completed. Handled integrity constraint error through exception block instead of joining table handle integrity constraint error from exception handle while purging data from ReadingGroup table. Reading_PurgeByPartition.sql was modified to resolve this issue.
Readings
2726276: (SR#: 01118164) The MDUS MeterCreate sets the DefaultSapMeterProgram which has MarketType = Electric ('1' in the DB) without regard for what market type the meter actually is.
Resolution: When more than one market type with a different name with a meter version is being returned, the code has been changed to allow more than one market type. This allows the readings to be processed and saved successfully.
2730727: (SR#: 01117534) IEE 10.2 Meter Reading Synchronizer consumes all memory, high paging, and eventually crashed the IEE application service and sometimes rendered the server inaccessible or unbootable.
Resolution: MRS appears to create files as expected in the working folder but does not move them to the root folder. Subsequent execution flushes out the contents of the working folder. If there are multiple entries in EXTERNALSYSTEMUOMMAPID for UOM, multiple entries from the same reading will result in returning distinct readings when multiple entries exist in EXTERNALSYSTEMUOMMAPID for UOM.
2861159: (SR#: 01136274) While importing files with multiple day data, there was a discrepancy as some of the days data was not being rejected.
Resolution: If there is a difference in ‘Number of interval readings’ and an actual number of interval reading records in the XML file of if the file has only one day's worth of data with the above-mentioned discrepancy, it gets rejected. And if the file has more than one-day worth of data with the above-mentioned discrepancy, then it is successful. The code has been changed to reject reading data if there is any difference between ‘Number of interval readings’ and the actual number of interval reading records in the Reading XML file.
2881734: (SR#: 01182534) Register readings are not being imported when the readings for both sides have critical changes.
Resolution: After fetching the register channel for the reading date range (in case of critical change) the read time span is being checked for all register channels before critical change and after critical change, and when reading time span doesn’t fall in any of the channels, neither before critical change nor after critical change, then reads are being discarded. This is working as expected, no changes were made.
2910318: (SR#: 01194353) The service point time zone details were not being saved in the dictionary properly causing a memory build up when MRS is executed.
Resolution: The code was changed so that the processing happened properly without consuming memory.
3048468: (SR#: 01271318) The Reading import task never completed and consumed all the available app server memory.
Resolution: When we reused the same endpoint for different Meters at different points in time, IEE fetched the Meters based on the endpoint ID, and then tried to find the service point linked to that meter. In this case, IEE identified the previous meter, which had already ended and was trying to import readings for this meter, which is what caused the issue. Now, the meters based on the reading period are being identified, which identifies the correct meter to import.
Reports
2953451: (SR#: 01217820) Usage data was shown truncated in the TOU report when it had long number of digits, because the column size was too small.
Resolution: The TOU report column size has been increased. The usage data is no longer truncated.
3301826: (SR#: 01400680) Customer could not see all of the Export File Name field on the Coincident/Noncoincident Peak report.
Resolution: To resolve this issue, the code was fixed so that export file name is visible for the coincident/noncoincident report.
Service Mode
2803098: (SR#: 01144711) Both the start and end reads from Service Mode were being imported for all linked register channels.
Resolution: In the reading XML file, there is a tag called Start Read. Start Read should not save even though it exists in the contiguous interval reading set. But in the current code, IEE was saving it, which is what caused this issue. An Internal bug requested to save StartRead when it exists in the contiguous interval reading set. This bug fix is what caused this issue. As part of the fix, we rolled back the change made for that bug. Now Reading XML Import Enhanced will skip the Start Read when saving reads.
2804351: (SR#: 01143812) User was not able to schedule the Service Mode remote interrogation when batch included recorder that was missing in the Service Mode database.
Resolution: When the recorder is missing from Service Mode and Scheduletaskid and Recorderid are different, IEE was not setting missing recorder for configuration push. Recorder fetch was loading all the recorders in the system. The missing recorder has been set correctly so that only the missing recorder is fetched for configuration push.
Task System
3066273: (SR#: 01268725) Aggregation task ended in a warning status even though the data exists.
Resolution: Changed logic to log empty contributor warning only when data doesn't exist.
User Interface
3042989: (SR# 1268086) There was a delay in the user interface when loading the Task Template or Task Scheduler workbenches.
Resolution: This was occurring because loading identity is called 3 times when the user navigates to the Task Template or Task Scheduler workbench because we added 3 user combo box controls that are required in the Task parameters panel to do Reschedule, Reoccurring offset, and even it is repeating when we change Task Type in both workbenches, which causes a delay to load the UI. Itron.EE.Presentation.Win.UiPlatform.dll was modified to resolve this issue.
Validation
2867905: (SR#: 01172080) Validation task failing with ORA-00001: unique constraint (ITRONEE.PK_REGISTERREADING)
Resolution: Violation error was caused by the field “Validate Readings By Day” being set to true in the Validation task. While creating validation request for the registers, IEE was creating duplicate requests, which was causing the issue “Unique constraint error” while saving the duplicate readings. While creating Validation requests for the registers, we checked for the existing request before adding the new request to avoid unique constraint error while saving readings.
3135156: (SR# 01314624) When there was a file share latency, VERunner service was trying to process the workbin file before moving the file to the actual folder.
Resolution: Implemented retry logic for the workbin file check for 3 times with incremental delay.
3146799: (SR# 1320137) The Validation log and Report page fields were being truncated.
Resolution: This was happening because we were limiting the number of digits/characters to be displayed to 15 when the length is more than 20 for the external recording device ID. The logic has been changed to increase the length of the external recording device ID as per the column size of the database. Itron.EE.Facade.Task.Validation.dll was modified to resolve this issue.
3180367: (SR#: 01347855) The user defined Validation rule was failing the validation even when it was set to WARN.
Resolution: The formula was looking for a combination of the ACHOS_Named_formula with a non-zero usage. To resolve this issue, the Validation rule value is now set to 1.
Web UI
3340250: (SR#: 01412183) The Reading REST API was frequently timing out.
Resolution: When the Reading microservice is used, it creates new connections and reaches maximum connections. The code has been integrated from 10.4 to 10.3, and the connections have been closed so that connections are used for pooling. ReadingAPI and IEE.Common components were modified to resolve this issue.
3336202: (SR#: NA) Customer was receiving an error in the Web UI pertaining to IEE 10.3 Service Pack 1.
Resolution: Customer was not able to upgrade the 10.3 Base to Service Pack 1 due to the missing assemblies. Web UI 2.4 assemblies were updated with changes related to Retail Settlement from IEE Core.